Conversation
| </PropertyGroup> | ||
|
|
||
| <PropertyGroup> | ||
| <CppWinRTBuildVersion Condition="'$(CppWinRTBuildVersion)'==''">2.3.4.5</CppWinRTBuildVersion> |
There was a problem hiding this comment.
While we're at it, maybe even 3.99.99.99, or 3.255.255.255? Now that we're going to break out of the fossilized "2.0" version, it doesn't seem far-fetched to have more than 9 minor releases...
There was a problem hiding this comment.
Yeah, either sounds good to me.
|
I kinda started moving my stuff to rust lol but I'm totally on board for a cppwinrt 3.0! Some wishlist item would be:
|
|
I strongly recommend setting the minimum C++ standard requirement to C++20. MSVC will eventually phase out experimental coroutines, and using C++/WinRT without coroutines is almost meaningless. If someone insists on using C++17, they can still use the older version of C++/WinRT. I think C++/WinRT should implement coroutines on its own for now, because WIL has its own pace and habits, and any lack of synchronization in implementation and usage would harm users. C++/WinRT 3.0 should also not continue the mistake of treating string_view as a null-terminated string. In addition, it is highly likely that MSVC will stabilize C++23 this year. Although I don't think C++23 will bring any fundamental changes, I believe it is necessary for C++/WinRT to follow the standard. Incremental upgrades are easier than all-at-once upgrades. New code should also use the best implementation and avoid relying on inferior implementations. |
|
I have a list of potential improvements for cppwinrt, some of them may be very controversial, but this represents my ideal vision. In addition, AI performs very well in mechanized refactoring, such as changing string_view to cstring_view. |
|
There is a 10-line version of zstring_view that inherits from std::string_view in WIL. This implementation is not compatible with future C++ standards, so I strongly advise against using it. See #1531. |
|
If we're making a break then we should also pull in #1446 |
|
Suggestion: Split off some sort of "release/2.0" mainline branch before merging this PR. That way if something unexpected comes up and we need to try to hotpatch 2.0.x.y we would have the ability to do so without having to migrate all usage to a post-break 3.x version. |
|
Yeah, that's reasonable. We can do a new branch and without the changes since the merge.
I still suggest adding something to smooth over the transition to the nuget, like the snippet I put to auto-generate a fusion manifest for reg-free activation. The PR breaks many scenarios currently, for example Win2D & WebView2 no longer works unpackaged until you manually add a fusion manifest. |
We already have cppwinrt bits that are effectively deprecated and replaced in favor of WIL bits, as well as WIL bits not present in cppwinrt. We should move everything over in one place for consistency. I don't particularly mind wether it's cppwinrt or WIL, but it has to be a single place. |
That's what #1521 was for. We are no longer using experimental coroutines, and now use the C++20-compatible coroutines via |
|
These version numbers should be consistent; it has caused me trouble before. |
|
I think that is a fair point. Local, unofficial, builds should have a version number that is clearly and obviously different than any official build. "2.3.4.5" is arguably too similar to the official builds that begin with "2.*". My vote would be that the local build version is either extremely low or extremely high. "0.0.0.1" or "999.999.999.999" or something along those lines. Probably a high number because there are some version checks in other libraries (e.g. WIL has a 2.x.y or greater constexpr check). Edit: Here's the version check in WIL https://github.com/microsoft/wil/blob/3ecba603d9789435b0661be7b7154d45c195ef98/include/wil/cppwinrt.h#L251 |
4 participants
We've removed support for deprecated
<experimental/coroutine>, which is bound to break some consumers.This seems as good a time as any to start adopting some practices of Semantic Versioning, by trying to limit breaking changes to major version numbers only.
Not every major version number needs to be a seismic shift. We just need to ensure that the project is moving forward with care, and that we aren't needlessly breaking consumers.
In this case, the breaking change is being pushed by external forces (the deprecation of the old coroutine header). Consumers using cppwinrt without any build customizations (either raw or via NuGet) should continue working. But, there are bound to be some consumers that were manually using the old headers via "/await" that will break. So let's simply pull the trigger now, and get our users off the old deprecated headers.
Ideally, this is the first of many more releases, and signals a willingness to consider future updates.
While we're at it, I want to start a discussion somewhere about lighting up an "experimental" channel where we can try out new features that might still need some real-world experimentation and feedback. Modules, in particular, comes to mind.
Discussions might be a good place to invite conversations about possible future breaking changes, or what else might constitute a major version update. There's an old "3.0" issue that was closed out a long time ago, but it wasn't tied to any particular feature. Perhaps we can port over the relevant points to a Discussion.
I know this is a bit of a shift, so I'm curious to hear feedback from other maintainers.